1. Field of the Invention
The present invention relates to a database system and, more particularly, to control of copying transactions from one database to another database.
2. Description of the Related Art
In business sectors, the importance of IT systems is becoming greater and greater. For example, in the financial industry, an IT system breakdown is estimated to cause a loss of hundreds of billion of dollars. Accordingly, a high availability (HA) technique is becoming important which provides duplicated computing systems at a primary site and a secondary site. In case failure should happen in the primary site computing system, failover occurs automatically to the secondary site computing system to keep the service on.
While system failure may occur due to diverse causes such as system errors, human-induced operation errors, and power failure, a Disaster Recover (D/R) technique attracts attention in which service and IT system recovery is quickly performed even in case of a large-scale disaster happening. In the D/R technique, data copy is performed between duplicated computing systems at the primary site and the secondary site to provide data integrity and the most important requirement is data integrity, that is, there shall be no missing data. Moreover, there is an increasing need to build the secondary site system at a remote location from the primary site for countermeasures against large-scale disasters.
A conventional D/R system configuration is shown in FIG. 16.
The conventional D/R system is comprised of a primary site 100 and a secondary site 110 which is remote from the primary site. The primary site 100 carries out operations such as data recording and search. On the other hand, the secondary site 110 stores the same data contents as stored on the primary site 100 and functions as a backup site of the primary site 100.
Each site 100 (110) is comprised of a server 101 including a DBMS 103 and storage (DB) 102. Both the sites 100 and 110 are connected by a server-to-server network 122 and/or a storage-to-storage network 121.
The primary site 100 receives input from a client 130 (user application (UAP)) and permanently saves results of operation in response to the input to the DB 102. The input from the UAP is ordinarily recognized as a transaction. Here, the transaction consists of a plurality of queries written in SQL that is a standard language for the DBMS (data management system). There are several types of queries: e.g., Insert, Update, and Commit. If a query which is included in a transaction and other than a commit is executed, the result of the query is only stored into a buffer within the DBMS 103 on the server 101 in the primary site 100. Only after the commit is executed, the results of a series of queries in the transaction executed until the commit execution are permanently saved to the storage 102 and the transaction is fixed. The primary site 100 copies the transaction and the data as the results of the transaction execution (registered in a table or the like in the DBMS) to the secondary site 110 at any timing. In case failure should happen in the primary site, failover occurs automatically to the secondary site 110 and the secondary site 110 which was being the backup site takes over the operation and executes it.
Conventionally, copies through the server-to-sever network 122 have been performed to copy transactions from one site to another site. Meanwhile, “EMC Symmetrix Remote Data Facility (SRDF)” (http://www.emc.com/products/product_pdfs/ds/srdf_ds—1523-7.pdf) discloses that copies through the storage-to-storage network have lately been applied and the reason hereof is that loads on the servers are eliminated during a copy and the storages are higher reliable than the servers.
These copies may be performed in either synchronous (sync) copy mode or asynchronous (async) copy mode, independent of the server-to-server and storage-to-storage networks.
For a sync copy from the primary site 100 to the secondary site 110, when the server 101 in the primary site issues a sync copy command, data to be copied is written to a disk cache in the storage (primary) 102 connected to the primary site. Then, the storage (primary) 102 copies the data to a disk cache in the storage (secondary) 112 in the secondary site. When having received a data receive acknowledge response from the storage (secondary) 112, the storage (primary) 102 returns a sync copy complete response to the server 101 that issued the data copy request. By executing the sync copy to the secondary site 110 in synchronization with a commit, data copy with no possibility of losing data is achieved. However, the sync copy involves delay for a wait time for the response from the storage (secondary) 112 and such delay becomes a problem when the distance between the sites is long.
On the other hand, when an async copy is applied, as soon as data to be copied is written to the disk cache in the storage (primary) 102, the response is returned to the server 101 that issued the data copy request and the copy of the data to the storage (secondary) 112 is performed at appropriate timing. This copy mode involves no delay, but it is not ensured that the data is copied to the secondary site 110 when the response is returned to the server 101 that issued the data copy request and there is a possibility of missing data.
JP-A No. 2002-045917 discloses a method that combines the async copy and the sync copy, which is regarded as intermediate between these modes and uses a command for confirmation of async copy complete. According to this method, the async copy mode is performed when synchronization is not required and the above command is executed when synchronization becomes necessary. Subsequent processing is suspended until it has been confirmed that the async copy is complete, thereby effecting copying data from one site to another site with no possibility of losing the data.
In the D/R system, when failure occurs in the primary site, after recovery processing such as confirming the consistency of the databases is performed in the secondary site 110, the system operation continues in the secondary site 110. If the async copy mode is applied, complete recovery cannot be performed because missing data may occur. On the other hand, even if the sync copy mode is applied, recovery processing in the first phase after the detection of failure may require much time. For example, recovery may be performed, using a full backup copy for a long period and incremental backup copies from the full backup. In this manner of recovery processing, after the full backup is initially restored and incremental backup copies are sequentially applied. Thus, the time required for the recovery processing increases, according to the size and number of data sets to back up
The above-described conventional D/R system has the following problems.
In order to carry out copying transactions from one site to another site without losing transactions, the sync copy mode is generally used, but delay for awaiting a sync copy complete becomes a problem especially when the distance between the sites is long. If the async copy mode is used, no delay occurs, but it cannot be ensured that transactions are copied to the secondary site. In other words, copying transactions from one site to another site with no possibility of losing the transactions cannot be fulfilled.
If the async copy mode is used, missing transactions may occur and complete recovery cannot be performed in case failure should occur. Even if the sync copy mode is used, in the first phase of recovery processing after failure occurring, recovery by updating difference from the full backup (incremental backup) requires much processing time and quick operation recovery cannot be performed.
Accordingly, it is desired to realize a D/R system which carries out copying transactions from one site to another site without losing the transactions, while minimizing the influence of copy operation on the transaction processing performance between remotely located sites.
For such a D/R system comprising remotely located sites, it is desired to carry out quick recovery after failure detection.